Cryptographic statements such as, for example, but not limited to, X.509 certificates and XrML licenses, enable secure and verifiable communication. To validate the status of or the trustworthy nature of a cryptographic statement, it is often necessary to acquire additional information, which may be referred to as cryptographic evidence. This cryptographic evidence may include references to additional cryptographic statements. The cryptographic statement that is being validated may include a number of locators such as, for example, uniform resource locators (URL's), that point to the locations of the necessary cryptographic evidence. To retrieve this cryptographic evidence, a number of different cryptographic evidence retrieval schemes have been developed. These schemes may include protocols and methods such as, for example, but not limited to, a certificate revocation list (CRL), online certificate status protocol (OCSP), simple certificate validation protocol (SCVP), and delegated path validation (DPV).
CRL is an earlier developed cryptographic evidence retrieval scheme that bundles evidence for a collection of cryptographic statements onto a single list. The list may be downloaded and cached so that it is accessible to a client. When one of the cryptographic statements within the collection is being validated by the client, the necessary evidence within the list is identified and re-validated. If the cached evidence is no longer valid, then an on-demand wire retrieval process may be used to obtain the updated valid evidence. CRL is advantageous because, assuming that the evidence on the list is still valid, it alleviates the need to retrieve evidence every time a cryptographic statement is validated. On the other hand, however, CRL is limited in that it requires an entire list of evidence to be downloaded even if only a small number of cryptographic statements need to validated. This limitation may be analogous to downloading an entire telephone book when there is only interest in small number of telephone listings.
To overcome this problem, later developed cryptographic evidence retrieval schemes focused on reducing the quantity of evidence that needed to be downloaded. In particular, OCSP is a cryptographic evidence retrieval scheme that enables a CRL list to be partitioned down to indicate a validation status for a single cryptographic statement. OCSP may be analogous to dialing directory assistance, rather than downloading an entire telephone book, to obtain information for a single telephone listing. While OCSP obviously provides advantages in scenarios where a smaller number of cryptographic statements are being validated, the effectiveness of OCSP is limited, often when a larger number of cryptographic statements are being validated. In particular, OCSP requires a query to be submitted every time that a known set of cryptographic statements needs to be validated, and a typical OCSP response is one to two kilobytes in length. Accordingly, when a large number of independent or duplicate cryptographic statements from the same issuer are being validated, it is often more economical to use CRL rather than OCSP. For example, if each OCSP response is assumed to be two kilobytes, a client may request, retrieve and cache 100 megabytes or more of OCSP responses after validating 50,000 cryptographic statements. By contrast, if each CRL entry is assumed to be 80 bytes, a CRL list with 50,000 entries will only be 4 megabytes in size. Moreover, in addition to requiring caching of a larger amount of data in the aggregate, the employment of OCSP may also require the management of a larger number of objects. Furthermore, implementation of OCSP may also result in additional protocol overhead in comparison with implementation of CRL.
In addition to the problems set forth above, OCSP is also limited in that it may result in user experience problems arising from problematic network conditions. For example, the retrieval can be time consuming due to, for example, the size of cryptographic statements being retrieved, connection bandwidth, network load, server load and bandwidth, and network latency. The retrieval may also fail due to, for example, server unavailability, the physical location of the user, network equipment failure, and other like problems. These limitations are amplified by the fact that a cryptographic statement often has a limited life span, and, once this life span has expired, the cryptographic statement typically cannot be relied upon. Conventional applications typically handle this problem in one of three ways: prompting the user with an often incomprehensible message; failing the operation; or simply assuming that the statement is trustworthy and ignoring the retrieval failure.